Nix Pills
Nix公式のdocsとかが難しいので概要まとめました的な文書 「前回の章で説明したように~」というのが毎回出てくる感じがあるので頭から順に読んでいくほうが良い
これも割と長いので全部読むのは気合がいりそうmrsekut.icon
記事の中でnixのmanualへのlinkが頻繁に貼られているが、全部リンク切れしている
悲しいmrsekut.icon
既存のpackage managerはmutableなglobal stateを管理している感じ
1つのversionを壊さずに、新たに他のversionを入れられない
Python用のvirtulenvや、GENOME用のjhbuildなど複数のpackage managerを組み合わせるで生じる複雑製の問題
同じLibraryを共有している場合でも毎回recompileしないといけない問題
Nix makes no assumptions about the global state of the system.
依存関係解決アルゴリズムもない
derivarationから別のderiveationを直接使用しているだけ
nix storeは全てimmutabel
When upgrading a library, most package managers replace it in-place. All new applications run afterwards with the new library without being recompiled. After all, they all refer dynamically to libc6.so.
この辺がわからん
/nix/var/nix/dbにsqliteのDBがある
derivationどうしの依存関係などを管理している
sqlite3が入っていれば、$ sqlite3 /nix/var/nix/db/db.sqliteで覗ける
$ nix-env -e '*'
と書いてたので説明読まずに実行したらhome-managerとかがuninstallされてビビったmrsekut.icon
$ nix-env --rollbackで戻せる
偽のderivationをbuildしてみたり、derivationの定義を見たりする
かなり詳しい
理解できない部分も多分にあったのでまた再読したいmrsekut.icon*2
In Nix, first the Nix expression (usually in a .nix file) is compiled to .drv, then each .drv is built and the product is installed in the relative out paths.
Nixがないときは、build時にいくつかのコマンド列を実行したいときはよくShellScriptが使われる
下記を実行すると
code:bash
declare -xp
echo foo > $out
この$outのpath<hash-name>にfileを作る
汎用的なbuilder.shを書いて、
default.nixの書き方を少し変えるだけで良い
set1 // set2という演算子は、JSの{...set1, ...set2}と同じmrsekut.icon
recordをmergeしつつ、fieldがconflictしたら後者を優先する
2段階
code:autotools.nix
pkgs: attrs:
with pkgs;
let defaultAttrs = {
builder = "${bash}/bin/bash";
buildInputs = [];
system = builtins.currentSystem;
};
in
derivation (defaultAttrs // attrs)
code:hello.nix
let
pkgs = import <nixpkgs> {};
mkDerivation = import ./autotools.nix pkgs;
in mkDerivation {
name = "hello";
src = ./hello-2.10.tar.gz;
}
hello.nixでは書き換えたい一部のattrだけを指定すれば良い
9. Automatic Runtime Dependencies
Build時の依存関係は今まで見てきたとおり
人間が指定して、derivationとかnix storeのpathとかで管理する
では、Runtimeでの依存関係は?について
うーん、この辺の話全然わからんmrsekut.icon
この辺の周辺知識が欠けている
builder.shの内容とかは8章で書いたものを指している
derivationをbuildするのではなく、buildを手動でする為の準備を提供する
あー、nix-shellの本来の機能がそういう感じなのかmrsekut.icon
.nixを元に、分離した環境を作る、というのが本来の機能
nix-shellを実行すると、builder.shは実行されてbuild済みの状態になっている
が、installはされていない
なんか微妙に思ってたのと違うなmrsekut.icon
11. Garbage Collector
12. Inputs Design Pattern
The single repository pattern
Debianとかは小さなrepoに分散させるが、これは変更を追跡するのが難しい
あー、nixpkgsとかDefinitelyTypedみたいなrepositoryの話ねmrsekut.icon
top-levelでNix言語で書いたものを個々で利用することができる
Nixpkgsの中でやっていることを自分でやってみているのか
buildInputsでLibrary名を書くだけで入れられるのは内部で12.4のようなことをやっているからなのねmrsekut.icon 結局なんでpngが使えるようになったのかわからなかった #?? たぶん
14. Override Design Pattern
14.1. About composability
14.2. The override pattern
14.3. The override implementation
14.4. Conclusion
14.5. Next pill
15. Nix Search Paths
15.2. Fake it a little
15.3. The path to repository
15.4. A big word about nix-env
15.5. Conclusion
15.6. Next pill
16.1. The default.nix expression
16.2. The system parameter
16.3. The config parameter
16.4. About .nix functions
16.5. Conclusion
16.6. Next pill
18.1. Source paths
18.1.1. Step 1, compute the hash of the file
18.1.2. Step 2, build the string description
18.1.3. Step 3, compute the final hash
18.2. Output paths
18.3. Fixed-output paths
18.4. Conclusion
18.5. Next pill
19. Fundamentals of Stdenv
19.1. What is stdenv
19.2. The setup file
19.3. How is the setup file built
19.4. The stdenv.mkDerivation builder
19.5. Conclusion
19.6. Next pill...
20. Basic Dependencies and Hooks
20.1. The buildInputs Attribute
20.2. The propagatedBuildInputs Attribute
20.3. Setup Hooks
20.4. Environment Hooks
20.5. Next pill...